Subject: Goals for Connect/Disconnect SIGlet

From: "R. C. (Roy) Dixon" <[email-masked]>
Date: Tue, 10 Aug 93 14:00:00 EDT

Reference:  Note from Alan K. Bartky (5 August 1993)

I would like to comment on the goals for this SIGlet based upon the
original objectives behind the concept of data link switching.  The
concept was introduced to provide a routing like environment for those
protocols (e.g., SNA and NetBIOS) that did not have a network layer
protocol characteristic of other connectionless routing protocols.
The exact technical approach grew out of proposals that were suggested
independently from two separate customer accounts.

The concept was to provide switching of data traffic from one data
link to another, where a data link was defined according to the
IEEE 802.2 (LLC) standard.  A data link can be either a logical data
link employing Type 1 LLC services or it can be a data link connection
employing Type 2 LLC services.  Based upon IEEE 802.2, a data link is
identified by the combination of the source address (MAC and LSAP) and
destination address (MAC and LSAP).

                               +-----------+
             Data Link (A)     | Data Link |    Data Link (B)
          <----------------->  |   Switch  | <----------------->
         MAC              MAC  +-----------+ MAC              MAC
         LSAP             LSAP               LSAP             LSAP

Within the RFC, the association between the two data links (A and B)
is defined to be a circuit.  Such a circuit can support either Type 1
or Type 2 LLC services.  Just as in any router network, the LLC
procedures on each data link operate independent of each other.

      (Note that connectionless routing protocols also provide an
       association between two data links, but the association is
       dynamic on a packet by packet basis.)

I would like to encourage that any enhancements to the RFC be designed
in concert with these original objectives.  As a consequence, my
answers to Alan's questions are as follows:

1) If possible, differences between end systems should be handled
locally within each DLSw.  This includes specifics relative to PU type
and link type (see the note from Randy Murphy dated 26 July 1993).
Furthermore, non-equal Link SAPs should be supported.  The current RFC
allows for such support (see the forthcoming note from Steve Klein).

2) Both SNA and NetBIOS should be supported through data link switching
due to the predominance of these protocols within the marketplace.
Furthermore, data link switching is important for UI frames since it
provides for local termination of the source routing information.

3) The current mechanism for establishing a circuit should not be
modified.  Support of Type 1 LLC services is equally important as
the support of Type 2 services.  For example, the NetBIOS 4.0 code in
LAN Server 3.0 employs UI frames for session traffic if the data link
is determined to be reliable.

4) The only other protocol that I know that uses LLC Type-2 is the X.25
PLP for OSI connection-oriented network services over a LAN.  To date,
I am unaware of any requirement to support data link switching of this
protocol, but it might be a candidate for the future.

Regards, Roy